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^ PROCEDE D*ADMINISTRATION DE RESEAUX A UAIDE D'AGENTS INTELLIGENTS. 

tL'invention conceme un proc^d^ d'administration de 
lau faisant intervenir une plurality d'utilisateurs du re- 
seau et une pluralite de ressources et/ ou de services dispo* 
nibles dans le r^seau et destinies d §tre utilis^es par lesdits 
utilisateurs, caract6ris6 en ce qu'il comporte des Stapes 
consistant ^ informer le systSme de gestion de reseau des 
besoins des utilisateurs, et ^ infonner les utilisateurs des 
ressources et/ ou services disponibles dans le r6seau, de 
sorte que ledit systeme de gestion de r^seaiu puisse de fa- 
9on autonome ex6cuter des operations de gestion aptes k 
optimiser le fonctionnement du r6seau en fonctlon des be- 
soins des utilisateurs et des ressources et/ ou services dis- 
ponibles dans le reseau. 




6/4/2007, EAST Version: 2.1.0.14 



1 



2774191 



La pr^sente invention oonceme les procedes et dispositifs de gestion de reseaux 
d'ordinateurs, et phis pardculiSrement la gestion de la quality de servioe dans un r^seau . 

Phis preds^ment, Finvention conceme un proo6d6 pemiettant d'introduire et de 
5 prendre en compte les besoins des utilisateurs de r6seaux, aussi tnen utilisateurs finaux que 
foumisseurs de services, dans une structure de gestion de reseau, afin de permettre k des 
applications de gestion de reseau de decider en direct des operations appropriees de 
gestion de reseau, sans intervention humaine. 
Etat de la Technique: 

10 L'interconnexion mondiale des ordinateurs est aujourd'htd en passe de devenir 

une realite. Les reseaux font et feront de plus en phis partie de Tenvironnement quotidien, 
et permettront de gerer des applications pour une vari^e croissante de taches, allant par 
exemple jusqu'i la gestion teleconunandte de Tequipeinent m^iager et electrique des 
maisons. De tels reseaux, en tant que systemes distribu^ necessitent survdllance et 

15 adnunistration. Or les reseaux prives, comme par exemple les reseaux locaux ou ceux des 
pedtes entreprises, n*ont pas les mSmes besoins en tenne d'administration que les reseaux 
a Techdle niondiale. Pourtant, si la phipait des p6riph^ques partageables en reseau sont 
adnmustrables (via SNMP, pour « Simple Network Management Protocol » en 
terminologie anglosaxonne), seules quelques plateformes d'administration existent, 

20 spedfiquement congues pour les grands reseaux. 

La gestion de reseaux et la gestion de systemes (distribues ou non) ont ete 
pendant longtemps des activites differentes et separees, meme si elles presentaient des 
interactions, Recenraient, les deux activites ont connu une certaine integration, de sorte 
qu'il est maintenant possible a partir d'une plateforme de gestion unique de gerer de fa9on 

25 homogene des reseaux et des systemes. Des exemples de ce type d'int^ration sont foumis 
par rint^tion de NETVIEW (sohition de gestion de reseau connnerdaHsee par IBM) 
avec TME 1 0 (gestion de systemes distribues, de TIVOLI), ou par OPEN VIEW (sohition 
de gestion de reseau de Hewlett Packard) avec TNG Unicent^ (gestion de systemes 
distribues de Computer Associates). D *autres plateformes similaires existent sur le marche, 

30 mais aucune n'int^gre une foime de sensibilite ou de « consdence» des besoins des 
utilisateurs finaux, c'est a dire des profils d'utilisateurs exprimant la &9on dont TutiUsateur 
prevoit d'utiliser un systeme distribu^. 
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Tnoonvenients de Tetat de la Technique: 

L*absenoe de oommunicalion entre les applications d'administration et les 
systenies d'adniinistradon est la cle d'un proUeme majeur et encore sans solution a ce 
jour en mattere d'admimstradon de neseaux. 
5 Ainsi, dans les plateformes d'administration de r^seau dispodbles aujourd'hui, 

toutes les fonctions de gestion de reseau ne sont pas couvertes, car les plateformes 
existantes se focalisent sur la sintple surveillance du reseau et sur le rapport d'evenements. 

En outre, aucune application d'administration de reseau corniue n'est capable de 
gerer efificacement un reseau heterogene. De plus, les produits existants, bien que de 
10 fonctionalite limitee, sont chers et consommateurs de ressources et ne sont pas adaptes a 
depedtsreseaux. 

Enfin, dans les systemes et procedes d'administration de reseaux de Tetat de la 
technique, il n'est pas tenu compte des services qui seront utilises par les applications 
instaH6es sur le reseau, ni surtout d'un niveau de qualite de service attendu par un 

1 5 utilisateur ou une application. De ce feit, les applications, qui pourtant dependent de phis 
en phis du reseau, ont diffidlement aoofe a des informations le concemant . 

Une application a rarement la possibilite de detenrnner a Tavance si les 
ressources qu'elle requiert sont disponibles. Par exeraple, une application reseau qui 
repose sur un systeme de ficWers distribue n'a aucun moyen de savoir si la qualite de 

20 services requise n'est pas en train de se degrader. De ce fait, il arrive que la moindre 
degradation des ressources du reseau peut dramatiquement aflFecter la stabilite de 
I'application, voire Tempecher totalement de fonctionner. 
Arri6re plan de Tinvention: 

En raison des differents inconvenients mentionnes ci-dessus, une nouveUe 

25 approche de gpstion qui est dga souhaitable aujourd'hui dans les environnements complexes 
de reseaux, deviendra vitale dans le fiitur. En fiut, il est probable qu'a mesure ou Tusage de 
Tordinateur de reseau (NC: Networic Computer en terminologie anglosaxonne) tend a se 
devdopper, le reseau hii-meme va revetir une importance de phis en phis grande pour les 
udlisateurs finaux, et r6dproquement. 

30 Ainsi, il va devenir impossible de concevoir une infrastructure de gestion de 

reseau qui ne prenne pas en compte les besoins des utilisateurs finaux, puisque ces demiers 
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representent la plus importante source d'information pour conserver le foncdonnement 

optimal d*un enviroimetnent de reseau. 

Or ce foncdonnement depend & la fois des besoins des utilisateurs en termes 

de panimetres de quafite de service, que des caracteristiques de ToflFre de service disponible 
5 dans le reseau pour les utilisateurs a chaque instant. Et il est clair que les problemes 

d'administration lies a Tapparition d'applications mobiles ne peuvent plus etre traites 

eflScacement par les andennes approches de gestion statique et oentndisee des r6seaux 

Buts de rinvention: 

Le but principal de I'invention est par consequent de proposer un procede 
10 ^ des mecamsmes de gestion de reseau permettant de resoudre Tensemble des 

inconvenients des systemes d'administration de reseau connus dans Fetat de la techraque. 

Phis particulierement, un des buts de rinvention est de proposer un procede 

d'adniinistnition de i^seau simple, pemettant une mdlleure int^ration et collaboration 

entre les appBcations, et des platefoimes d'admirastration extensibles et peu couteuses. Un 
15 autre but de rinvention est de proposer un proced6 d'admirastration permettant de remplir 

automatiquement des tSches d'administi^on aptes 4 prendre en con 

utilisateurs du reseau. 

Un autre but de rinvention est de proposer une plateforme d'adminisatration de 
reseau qui soit a la fois flexible et extensible pour pouvoir prendre en compte rajout de 
20 ressources ou de services, et economique. 

D'autres buts et avantages de rinvention vont apparaftre i la lecture de la 
description suivante faite a titre d'exemple non limitatif; et aux dessins d-annexes, dans 
lesquels: 

- La figure 1 repr&ente un environnement reseau du type de ceux ou le procede 
25 de gestion selon I'invention peut etre nus en oeuvre; 

. La figure 2 represente sous forme schemarique une architecture de gestion y 
compris les prindpaux agents permettant de mettre en oeuvre rinvention; 

- La ^ure 3 represente sous forme schematique les dements d'un contexte 
d'application utilise pour mettre en oeuvre le proo&ie sdon rinvention; 

30 intrcNluire tableau page 92 

- La figure 4 repr&ente sous fomw schematique les dements d'une contexte de 
foumisseur de SCTvice utilise pour mettre en oeuvre le procede selon rinvention; 
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- La figure S represente un contexte d'applicadon et im constexte de foumisseur 
de service, pour deux types difFei^ rimpressionetleserveurdefichiers; 

- La figure 6 represente sous forme sdiemadque la stmctuie d'un agent 
intelligent pouvant etre utilise pour mettre en oeuvre le prooede sdon Tinvention; 

5 - La figuxe 7 i^inesente rintegradon d'agents intelligents dans un exemple 

d'environnement de rdseau; 

Prindpe de la solution: 

L'invention decrite phis en detail d-dessous est la premiere tentative de gestion 

integrant non seulement la gestion de reseaux et de systemes distribues, mais va phis loin 
10 en integrant egalement des informations concemant la faiyon dont les utilisateurs prevoient 

d'utiliser des services disponibles dans un environnement de r&eau d'entreprise, par 

exemple oomme cehii represente en figure 1 . Sdon Finvention, il est propos6 une methode 

et des outils pour introduirc dans TinfiBstucture de gestion de reseau, une connaissance ou 

une « consdence » des besoins des utilisateurs finaux et des ressources des foumisseurs de 
15 services, afin de permettre de dedder a la volee des operations appropriees de gestion de 

reseau, tdles que la surveillance, la coramande, le diagnostic, ou la reconfiguration du 

reseau, et ce sans aucune intervantion humaine. 

Dans la suite, on definira par mesure de amplidte la gestion de reseau avec 

connaissance des besoins des utilisateurs par la terminologie de « gestion avertie », qui 
20 serait mieux representee en temrunologie anglosaxonne par I'expression « aware 

numagement ». 

L'invendion conceme un procede d'administration de reseau faisant inter/enir 
une phiralite d'utilisateurs du reseau et une pluralite de ressources et/ou de services 
disponibles dans le reseau et destinees a etre utilisees par lesdits utilisatewrs, caracterise en 
25 ce qu'il comporte des etapes consistant a informer le systeme de gestion de reseau des 
besoins des utilisateurs, et a informer les utilisateairs des ressources et/ou services 
disponibles dans le reseau, de sorte que ledit syst&ne de gestion de reseau puisse de 
fa^on autonome executer des operations de gestion aptes a optimiser le 
fonctionnement du r6seau en fonction des besoins des utilisateurs et des ressources 
30 et/ou services diponibles dans le reseau. 

Sdon d'auties caract6istiques du proc^d^ degestion sdon Tinvention: 
. - il comporte des etapes consistant t 
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- rassembler les besoins des utilisateurs a partir des applications 
utilisatrices de ressources, et les capadtes de prestations des ressouroes et/ou services a 
partir des applications prestataires de ressources et/ou de services; 

- transmettre lesdits besoins et capadtes des applications i un 
5 environnement de gestion de reseau; 

- au niveau de I'environnement de gestion de reseau, trailer les 
informations repues et decider des operations de gestion a efTectuer pour que 
Tenvironnement de reseau fonctionne comme requis par les applications utilisatrices; 

- au cas ou Fenvironnement de reseau ne peut pas fonctionner comme 
10 demande, en informer les applications utilisatrices et/ou les applications prestataires. 

- pour rassembler les besoins des utilisateurs i partir des applications 
utilisatrices de ressources,. on utilise une stmcture d'information dynamique QdS 
representative des besoins de Qualite de Service (QdS), comprenant un en-tete de 
contexte d'appUcation et un bloc d'information representatif des specifications de qualite 

IS de service pour chaque service parmi une pluralite de services. 

- ledit bloc d'information representative des besoins de qualite de service 
comporte une sequence de dimensions de QdS, chaque dimension de QdS contenant une 
sequence de Domaines, et chaque Domaine contenant une sequence d'attributs de QdS. 

- pour rassembler les capadtes de prestations des ressources et/ou services k 
20 partir des applications prestataires de ressources et/ou de services, on utilise une 

structure d'information dynamique representative des oflfres de qualite de service a 
Tattention des utilisateurs, comprenant un en-tete de contexte de foumisseur de service, 
un bloc d'information representatif des specifications de qualite de ser\ace offertes par 
chaque service disponible, et un un bloc d'information representatif des specifications de 

25 qualite de service pour chaque service parmi une pluralite de services. 

- pour traiter les informations revues et deader des operations de gestion a 
effectuer, on elabore des taches de gestion abstraites a I'aide d'agents autonomes qui 
prennent en compte les besoins de qualite de servie QdS des utilisateurs, et les offres de 
service dans I'enwonnement du reseau. 

30 - de preference, lesdits agents sont des agents intelligents, comportant : 

- une couche avertie permettant d'acqu^ les besoins des utilisateurs du 
reseau et les offires de services; 
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- une couche deliberative chargee de creer des t§ches de gesdon; 

- une couche operationnelle executant les taches de gestion crees par la 
couche deliberative. 

Selon un aspect de rinventton, ta saisie des besoins des utilisateurs se &it par 

5 rinterm^diaire d'une interface homm&-machine comprenant un moyen d'entree 
d Wormation et un moyen d*afiBichage. 
Description detaillee des figures: 

On se r^e h la figure 1. On a represente dans cette figure un exemple de 
structure de reseau permettant de mettre en oeuvre Tinventioa L'environnement 1 

10 represente est compose de phisieurs domaines utiUsateurs, tel que cetui du cote gauche de 
la figure, un domaine de serveurs 2 ou sent situes les serveurs d'entreprise, et un reseau 
principal 3 permettant de federer toutes les communications soit pour acceder a des 
r^ssources du reseau dans Tentrepnse ou a Texterieu^^ 

Les utilisateurs finaux ou les applications expriment leurs besoins par 

15 rintermediaire d'une structure d'information qui sera appelee dans la suite un contexte 
d'appUcation ou Desiderata de Qualite de Service (QdS). Cette structure d'information 
detaiUe les s^ces et les attributs de QdS associes qui sont consideres appropries pour 
assurer un comportement correct de la part d^une plication. Un Desiderata de QdS est 
1 'dement qui permet a une plateforme de gestion d'atteindre une connaissance oonoemant 

20 les services en cours d^'utilisation, leur utilisateur, et la fa^on dont ces services sont utilises. 
De ce fait, il est egalement possible, grace k Tinventiori, d'en deduire le d6gre de 
satisfaction des utilisat^irs finaux de Tenvironnement de reseau, H doit etre rappde que ce 
qui a ete jusqu'a present lvalue dans Tetat de la technique, n'est que le degre de 
satisfaction du foumisseur de services^ au lieu du d^gre de satisfaction des utilisateurs 

25 finaux. 

La definition d'une structure capable de porter une combinaison de requetes pour de 
multiples services ayant chacun ses caracteristiques propres, implique la conception d'une 
structure d*information dynamique pour les Desiderata de QdS. 

30 On se r^fdre i la figure 2, qui represente de fa9on schematique Parchitecture 

d'un ensemble de gestion de reseau integrant les prindpaux iliments necessaires pour la 
mise en oeuvre du proced^ sdon Tinvention. 
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Cette architecture se focalise sur les agents AIs de QdS. Les AIs de QdS 
re9oiveiit, via une couche CORBA les besoins des applications (Application Contexts) et 
des foumisscurs de service (Service Provider Conte?rts). Us dialoguent ensuite (toujours 
via CORBA) avec un servcur SQL qui joue le role d'interface entre I'AI ct des agents 

5 SNMPs classiques. Ce serveur tradiut les requetes de I'AI (exprimees en SQL) en 
requetes de type SNMP a I'attention des agents SNMP, recueille les r^tats et les 
communique (sous forme SQL) a PAl. Pour de nombreuses raisons, un AI peut avoir a 
communiquer avec un autre AI. Dans ce cas, la communication se fait via des messages 
au format KQML encapsulant des messages specifies soit en KQML, soit en GDL.. Un 

10 agent Interface d'Agent a ete con9u pour assister les managers humains pour 
communiquer avec les agents intelligents, a Taide d'une interfitce graphique d'utilisateur 
(voir plus loin). 

L* Agent Interface est un agent sous forme d'applet qui permet k un manager a 
priori humain d'interroger et d'interagir avec des Agents Intelligents. La communication 
15 proprement dite se fait au moyen de messages par exemple au format KQML. 

Le routeur de messages inter-agents, ou AMR (Agent Message Router) 
est une application specialisee (un assistant de communication), qui a la reception d\in 
message provenant dW agent, le redirige vers Tagent destinataire. Les messages re^us 
sont gdres dans une file d'attente consenr6e sur le systeme de fichiers. 
20 Le serveur SQL joue le role d\m interprete entre AI et agents SNMP, le 

premier parlant SQL, les autres SNMP. 

Uinterface utilisateur est ime interface sous forme d'aplet (petite 
application) qui permet a un utilisateur de specifier directement ses desiderata en matiere 
de QdS. Cette interface n'a de vertu que demonstrative, puisqu'idealement ces desiderata 
25 seront essentiellement specifies directement par les applications. 

La connaissance des besoins des utilisateurs est une notion qui est absente des 
systemes connus de gesdon de reseau. De ce fait, la gesdon dite averde est un effort pour 
donner un sens a cette expression dans le cadre de systemes de gesdon de r6seau, de sorte 
que le resultat de la gesdon du reseau devienne plus satis&isante du point de vue d^un 
30 utifisateur final. 

On d6finit par consequent la « gestion avertie » comme etant la capadte d'un systeme 
de gesdon de decider de ses acti>at6s pour un environnement de reseau, sur la base des 
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besoins courants des utilisateurs. Cette gesdon avertie prend en compte des questions 
Gomme: qui sont les utilisateurs finaux ? Quels sont leurs besoins courants de service ? 
comment sont-ils logiquennent organist ? Ou sont-ils situes, e^. 

Les besoins des utilisateurs et les oflfres de services devant dtre pris en compte, tl 

5 devient n^cessaire de trouver une &Qon d'exprim^ les besoins des utilisateurs et les of&es de 
service a Taide de structures d'infonnation respectives £^>propriees. Ces structures 
d'information sont decrites en relation avec les figures 3 et 4. De fa^n gCTerale, chaque 
entite de QdS doit etre identifiee par un nom unique, qui est compose de son propre nom plus 
une concatenation des noms de toutes les entites QdS qui la contienent. Ainsi, le nom d*un 

10 Domaine de QdS doit etre du type [Nom de Service ][Nom de Dimension QdS][Nom de 
Domaine QdS]. Les besoins de QdS et les entites de service poss&lent ^alement un en-t^ 
d'entit^ contenant des informations generiques par rapport a eux-memes. 

Toutes les ^)edfications de QdS doivent suivre les recomnneDdatiom 

On se re&e a la figure 3 pour d6crire la structure d'un besoin ou desiderata de QdS. 

IS II contient les specifications de service de chaque service que Tapplication requiert pour 
fonctionner correctement. Une specification de service contient cUe-mSme ime Uste de 
conditions (contraintes) implidtes sur des attributs (parametres) de QdS associes au 
service. Ces attributs de QdS sont logiquement organises de facon hi^rarchique en 
Dimension de QdS et Domaine de QdS. Toutes les specifications de QdS doivent suivre 

20 ces regies. L'avantage d^une telle approche est qu'elle permet a I'Agent de travailler a un 
niveau 61ev6 d'abstraction. Ainsi un Agent peut se voir amene a prendre une decision en 
se basant seulement sur la EHmension de QdS plutot que sur chaque attribut de QdS de 
chaque Domaine de QdS de la Dimension de QdS. 

Les besoins de QdS sont a la base d'une gestion avertie, au sens de Tinvention, 

25 Une telle entite comporte toute Tinformation concemant tous les services utilises, 
comment et par qui ils sont utilises, et avec quel niveau de priorit6. 

La structure d'un contexte d'application (ou besoin de QdS) comporte un en-tete 
de contexte d'appliccUion, ou des informations generates concemant Tapplication 
d'utilisateur final sont stock^es, et des besoins de services, dans lesquels sont stock6es 

30 les spedfications detaillees de chaque service. La table 1 ci-dessous donne ie detail de ce 
premier niveau de contexte d^application: 
Table I: 
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Nom 


Signification 


En-tete de contexte 
d'application 


Description generale de Tapplication presente dans 
renvironnement de reseau 


Besoins de Services 


Bloc d'informations ou sont inclus les specifications de QdS pour 
chaque service 


La table 2 represente les attributs de Ten-tete de contexte d'application qui identifie 
Tapplication d'utilisateur final et I'utilisateur qiii utilise Tapplication. 


Table 2: 




Nom 


Signification 


Nom d' Application 


Nom que I'editeur de logiciel a donne i I'application 


Type d'application 


Caracterisation du role de I'appUcation dans I'environnement de 
reseau (session d'utilisateur) 


Identification 
d"" Application 


Distingue deux applications du meme type lancees dans le meme 
bote. 


Nom d'utilisateur 


Nom de I'utilisateur qui est responsable de cette application ou 
est en train de Tutiliser 


Identifiant 

d'utilisateur 


Identifiant de I'entreprise de Futilisateur 


Nom de Host 


Nom du noeud de reseau ou rapplication est situee 


Priorite 


Priorite donnee par Futilisateur a cette application 



Les besoins de service soot composes d'une sequence de contextes de SCTvice, 
representes dans la table 3. 



10 Table 3: Principaux blocs d'un contexte de service 



Nom d'attribut 


Signification 


En-tete de contexte 
de service 


attributs generiques concemant un service selcectionne 
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S^uence de 
dimensions de QdS 


les dimensions de QdS constituent le premier niveau de detail 
ayant trait a des demandes d'utilisateurs pour un service donne 


Sequence de 
Ressources 


Ressources de service requises par Fapplication de ce service 



Table 4: attributs definis dans Ten-tete de contexte de service 

5 ' 



Norn d'attribut 


Signification 


En-tete de contexte 
de service 


attributs generiques concemant un service selcecttonne 


Sequence de 
dimensions de QdS 


les dimensions de QdS constituent le premier niveau de detail 
ayant trait a des demandes d'utilisateurs pour un service dorme 


Sequence de 
Ressources 


Ressources de service requises par Tapplication de ce service 


Table 5: Attributs definis dans le contexte de service 


Nom 


Signification 


Service 


nom gen^ralement accepte pour le service 


Foumisseur de 
Service 


nom du foumisseur de ser\dce, quelquefois identique au nom du 
systfeme qui Vhihevge 


Priorite 


Priorite du service pour I'application qui Futilise 


Media 


decrit le type de media dont le service a besoin, tel que: donnees, 
vid6o, audio, etc. 


Engagement 


decrit la classe d'engagement que Tapplication utilisant ce service 
attend a partir de la plateforme de gestion, tel que: meilleurs 
efforts, statistique, deterministe. 



10 



On se refere a la figure 4 pour decrire la structure d'information representative du 
15 contexte de founrisseurs de service. Les Dimensions de QdS et Domaines de QdS 
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specifies dans le Contexte d'application correspondent evidemment a ceux definis par les 
foumisseurs de service. Ces demiers expriment leur capadtes dans des Contextes de 
foumisseurs de service, qui contiennent des attributs de QdS (hierarchiquement organises 
en Dimension de QdS et Domaines de QdS) que le foumisseur de service est capable 
d'oflfrir. Les foumisseurs sont responsables de rinstmmentation du service, i.e doivent 
non seulement specifier les attributs de QdS les plus appropriees pour le service, mais 
aussi les outils de mesure permettant de les surveiller. 

La figure 5 recapituie sous forme sch6matique les structures d'information 
representatives d'un contexte d'application et du contexte de foumisseur de service, 
pour deux exemples de services souvent utilises en pratique: un service de serveur de 
fichiers (note DFS), et un service d'impression (note DPRINTING). 

Le procede de gestion selon I'invention et les entites et structures d'information 
utilises peuvent etre de preference mis en oeuvre i Taide d'agents autonomes intelligents, 
notes AI. L'AI est One composante centrale de la strategie de gestion. Ses propriety 
sont les suivantes: 

Reactif, dte Vapparition d'un probldme Tagent doit definir les mesures 
appropriees i prendre et eventuellement employer les outils a sa dispositions pour agir 
sur la source du probleme. 

Proactif, il doit anticiper Tapparition des problemes et chercher a an^liorer les 
performances du systeme avant que les valeurs critiques des seuils ne soient atteints. 

Autonome, il doit posseder une certaine autonomic de decision quant aux 
reponses a apporter en cas de pannes, et ne notifier le manager que lorsque le probleme 
depasse ses competences. En revanche, il doit toujours notifier les applications des 
moindres degradations voire intermptions d'un service dont il garantit la QdS. 

La figure 6 donne une representation schematique d'un mode de realisation 
d'un agent intelligent pouvant fitre utilise pour mettre en oeuvre le procede de gestion 
selon I'invention. On peut distinguer 3 couches dans Parchitecture d'un Agent 
Intelligent (AI). 

La premiere couche, que Ton appellera la «partie sensible)) (awareness layer en 
temunologie anglo-saxonne), se compose essentiellement du Gestionnaire de contextes 
(Context Manager). Ce Gestionnaire oflfre phisieurs interfaces, accessibles par tous les 
acteurs definis plus haut, a savoir les applications utilisateurs, les foumisseurs de service 



6/4/2007, EAST Version: 2.1.0.14 



2774191 



12 

et les applications d'administration. Grace a ces interfaces, le Gestionnaire de contextes 
peut gerer des informations oriente services de haut niveau. . 

-La «partie d61ib6rative» (ddiberative layer) forme la seconde couche, ou Ton 
retrouve principalement le Gestionnaire de buts d'administration (Goal Manager). 

-La «partie executive)) (operational layer) est la troisieme et demiere couche, 
et est formee par les procedures d'administration. Chaque but ^administration de la 
couche superieure est assodee a une intention d'administration qui represente les 
procedures d'administration decidees par I'M. 

On va maintenant decrire de fa9on plus detaillee chacune des trois parties 
des agents intelligents utilises dans le cadre de I'invention: 
1) Paitie aveitie: 

LAgent Intelligent (AI) 6tant typiquement destine a etre place dans un environnement 
distribue, on doit par consequent le doter de mecanismcs lui permettant de detecter les 
caracteristiques de son environnement, et en particulier, dans le cas pr&ent, les 
desiderata ou besoins des applications. 

Comme il est aujourdliui attendu que les systemes distribues du fiitur seront 
bases sur un paradigmc de communication via un <dangage neutro), tel que CORBA, VAI 
doit lui aussi proposer des interfaces, sp6cifies en CORBA IDL, aux appUcations, 
foumisseurs de services et systenies administration. 

Ces interfaces foumissent des methodes pour la negociation, publication et 
mise a jour des contextes. Les manipulateurs de contextes (Service, Dimension de QdS 
et Domaine de QdS) analysent les contextes re?us et les stockent dans des Bases de 
contextes. lis passent ensuite une reference des contextes fraichement re9us au 
Gestionnaire de buts d'administration. 
Le Gestionnaire de contextes - « Context Manager )> 

Le gestionnaire de contexte est charge de coUecter les desiderata des applications 
et foumisseurs, sous la forme de contextes d'applications et de contextes de foumisseurs 
de service, de les interpreter et de les passer a la couche inferieure. 
2) La Partie deliMrative: 

- Gestionnaire de buts d'administration « Goal Manager )> 

A la reception d\m contexte d'application (via la couche superieure), ou d'un but 
administration d'un tiers agent (via le module de communication), le Gestionnaire de 
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buts d'administration doit decider si un but ^administration doit localement etre cree ou 
non, en se basant entre autres choses sur un ensemble de politiques ddinies par les 
administrateurs de reseau. S*il d6cide de le creer, il le signale au module «Memoire», qui 
le conservera dans sa Base de categories mentales. Ainsi T AI pourra verifier au besoin si 

5 un but d*administration n*est pas deja planifie. 

Une autre decision est alors a prendre par TAl: faut-il traiter localement le but 
d*administration, le deleguer a un autre AI, ou les deux a la fois? En fait, la decision de 
deleguer un but sera prise si Tagent ne peut acceder a certaines ressources du systeme 
distribue car ne se trouvant pas dans son domaine, ou si I'Al estime ne pas etre 

10 suffisamment eflBcace pour traiter le but demande, car par exemple trop eloigne des 
ressources h gerer. Une fois de plus, cette decision est basee entre autres sur des 
politiques definies par les administrateurs de reseaux. 

Module de comaiuniGation - ^Conversation Dispatcher » Le gestionnaire 
de buts d*administration implemente une interface dediee aux echanges de categories 

15 mentales. Cette inter^sice doit etre accessible a tous les agents --puisqu'elle autorise les 
autres agents a deleguer un but d'administration, ou encore i obtenir des informations sur 
un but d'administration et les outils de mesure de service associes. 

D^ion de creation de but d'administration: Un but d'administration 
comporte un ensemble de conditions («desiderata») portant sur des attributs de QdS. 

20 Cette information est directement associee aux conditions definies par un contexte 
d'application. Ce dernier peut donner lieu a un ou plusieurs buts d'administration, 
puisqu'il peut y avoir plusieurs ensembles d'attributs de QdS (i.e des Domaines de QdS), 
et qu'un but d'administration depend au moins d'un domaine de QdS (il sera par la suite 
traduit en procedures d'administration). 

25 En se basant sur le contexte d'application (nom du service, les clients, les 

foumisseurs, sunsi que les attributs, domaines et dimensions de -^^S) et sur les 
politiques du manager, le Cerveau doit alors decider si oui ou non la creation d'un 
nouveau but d'administration s'avere necessaire. 

Pour une implementation possible, on peut decider d'implementer la rSgle 

30 suivante: / 'AI decide de creer un nouveau but: 

a) s'il n'y a aucun but d'administration deja present dans la Base de categoric mentale 
compoTtant le triplet (nom du service, dimension de QdS, domaine de QdS) 
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ou bien: 

b) si un td triplet existe, mais que raccompHssement du but associe n'implique pas 
raccomplissement du nouveau but. 

On peut voir le triplet ci-dessus oonune un index global de but 
5 d'adrainistration. L'AI peut utiliser cet index lore de la creation d^un nouveau but pour 
rechercher dans la Base de categorie mentaie si des buts similaires ne seraient pas d6j4 en 
cours, C'est rinfonnation minimale (extraite du contexte d'appUcation) qui permet de 
distinguer deux buts similaires. Bien sur, cet index depend de Tinterpretation de 
rinfonnation contenue dans le but.. . 
10 L'implication b) est un des elements qui font Finteliigence de I'M. II dit que 

si un but doit etre accompli, tout autre but impUque par lui n'a pas besoin d'etre 
accompli. Par exemple, si une application requiert un temps de reponse de 10ms pour le 
service NFS (serveur de ficheirs), et qu'il existe deja un but qui accomplit 5ms, le premier 
but est impliqu6 par le but deja existant et rfa par cons6quent pas besoin d'etre cr6e. 
15 Cette regie est clairement sp6cifique a un but, i.e la definition de cette implication peut 
are difFerente (et differemment implementee) pour chaque conibinaison de ISndex... 

Decbion de deKgation de but d^administration Le modele de decision 
verifie si le foumisseur de service requis est bien situe dans le domaine ger6 par I'i^ent. 
UAgent Intelligent est conscient de la presence de founusseurs de services puisqu'il 
20 re^oit des contextes de service de la part de chaque foumisseur de service. Par 
consequent la decision a prendre est implementee en recherchant dans la base des 
contextes de service le nom du foumisseur de service: 

- si le foumisseur de service se situe dans le domaine gere par I'agent, le 
but sera traite localement, puisque I'agent est capable de recuperer les outils qui 
25 instrumenteront le service ; 

si le foumisseur de service appartient a un domaine de gestion sur lequel 
I'agent n*a aucun droit, le but doit etre delegue. 

Par exemple, ^ une application a besoin d*acc6der au serveur Web d\m autre 
domaine de gestion avec un temps de reponse donne, au moins deux Agents (PAgent 
30 gerant le domaine ou se trouve I'application, et et celui gerant le domaine ou se situe le 
serveur Wd)) devront coop6rer (dans le sens ou ils devront travaiUer de concert) pour 
atteindre Tobjectif demande. 
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Implementation Le « Centre d'Operations » est en fait initialement assez 
« stupide », mais est pret a recevoir un moteur d'inference ou tout autre systeme de 
manipulation de connaissances. 

Cest au Centre de Dedsions de g6rer les priorites fixees par les managers, 
5 applications et foumisseurs de services, et les conflits qui peuvent en resulter. Par 
exemple, un foumisseur d'acces Internet souhaitera la plus haute qualite possible pour le 
service WEB, tandis qu'un etudiant imprimant son rapport de stage privilegera pour un 
temps le service d'impression DPRINUNG, pour rebasculer sur le service WEB une 
fois le rapport imprime. 

10 Cest encore au Centre de Decisions de decider de fusionner ou non des buts de 

gestions, ou encore de tenter de synthetiser ses croyanoes pour en degager les croyances. 
Dans une implementation possible, le Cerveau decide systematiquement de fusionner les 
buts. En ce qui conceme le second point, le Cerveau est aujourdliui capable de 
synthetiser les piriodes de non disponibilite d*un service donne, capadti qui peut 
15 fe<^ement etre 6tendue a des croyances plus generales. 

Mimoire (Memory) La memoire de TAI est un module qui pennet 
d'interroger et de manipuler la base de oonnaissance interne (KB) de VAI. Cest elle qui 
conserve et maintient les categories mental es de Tagent. 

ImpKmentation La Memoire est aujourdlitu implementee sous la fonne 
20 &un tableau associatif complexe, qui permet tfassocier a une cle soit une expression, soit 
un autre sous-tableau associatif complexe. 

Module de communication (« Conversation Dispatcher ») Le module de 
conversation de TAI est un module qui permet de communiquer avec autres agents. 

25 3) La Paitie executive 

La partie executive se fonde essentiellement sur le module Effectair (« Engine »). 
n peut effectivement etre compare aux bras de TAl, car il dispose de tous les elements 
necessaires pour mesurer la QdS, et au besoin de ramdiorer. 
Procedures d'administration: D y a trois types de procedures d'administration 
30 - Surveillance et mesure 

- Analyse et diagnostic 

- Reparation et configuration 
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Implementation On associe aux procedures d'administration des classes jouant le role d' 
outUs de raesure de QdS (« QoS Meter »), d\ outfls de diagnostic - (« QoS Diagnosis »), 
et & outil de configuration - (« QoS Configure ») 

5 On se refere a la figure 7 pour une illustration de I'utilisation d'agents 

intelligents en liaison avec un environnement de gestion de reseau donn6. 

Conclusion 

L'invention propose pour la gestion des QdS une solution bas6e sur des 
10 Agents InteUigents (AIs), jouant le role d'assistants vis-a-vis des appUcations, et 
permettant ainsi le maintien d*une QdS la plus proche possible de la demande. Pour 
pouvoir g6rer cette QdS individuellement par appUcation, les AIs ont besoin de connaitre 
leure desiderata. Les stiiictures dinfonnation choisies a cette fin sort du type oontexte, 
organisees suivant les divers services requis. 
15 L'invention teUe que decrite phis haut repond k ses objectifs, et pennet entre 

autres de faire en sorte que les leseaux puissent "etre au couranf des besoins et des 
comportements des applications, ce qui peut 6tre considere comme une forme 
d'«inteUigence» a fort potentiel, non encore explore. Cela pennet d'informer les 
applications des degradations de la qualite de service, et dV feire face, par exemple par la 
20 generation d'6v6nements ou alarmes, non seulement en cas de pannes graves mais aussi 
des que des degradations de la quaUt6 de service se font sentir de fa9Con individueUe, ce 
qui est totalement impossible aujourdliui. 
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REVENDICATIONS 

1. Proc6d^ d'administration de r^seau fitisazit intervenir une pluialite d'udlisateurs du 
reseau et une phiraHt^ de ressources et/ou de services disponibles dans le reseau et desdnees a 

5 etre iitilis6es par lesdits utiBsateurs, caracterise en ce qu'il comporte des etapes consistant 
a informer le systeme de gestion de reseau des besoins des utilisateurs, et i informer les 
utilisateurs des ressources et/ou services disponibles dans le reseau, de sorte que ledit 
systdme de gestion de reseau puisse de fa9on autonome executer des operations de 
gestion aptes a optimiser le fonctionnement du reseau en fonction des besoins des 

10 utilisateurs et des ressources et/ou services diponibles dans le reseau. 

2. Procede selon la revendication 1, caract6ris6 en ce qu'il comporte des 6tapes 
consistant a: 

- rassembler les besoins des utilisateurs a partir des applications utilisatrices de 
ressources, et les capacites de prestations des ressources et/ou services a partir des 

15 applications prestataires de ressources et/ou de services; 

- transmettre lesdits besoins et capacites des applications a un environnement de 
gestion de reseau; 

- au niveau de renvironnement de gestion de reseau, traiter les informations 
regues et decider des operations de gestion a efFectuer pour que Tenvironnement de 

20 reseau fonctionne comme requis par les applications utilisatrices; 

- au cas ou Penvironnement de reseau ne peut pas fonctionner comme demande, 
en informer les applications utilisatrices et/ou les applications prestataires. 

3. Procede selon la revendication 2, caracterise en ce que pour rassembler les 
besoins des utilisateurs a partir des applications utilisatrices de ressources, on utilise une 

25 structure d'information dynamique QdS representative des besoins de Qualite de Service 
(QdS), comprenant un en-tdte de contexte d'application et un bloc d'inforniation 
representatif des specifications de qualite de service pour chaque service parmi une 
plurality de services. 

4. Procede de gestion selon la revendication 3, caracterise en ce que ledit 
30 bloc d'information representative des besoins de qualite de service comporte une 

sequence de dimensions de QdS, chaque dimension de QdS contenant une sequence de 
Domaines, et chaque Domaine contenant une sequence d*attributs de QdS. 
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S. Procede selon la revendicatipn 2, caracterise en ce que pour rassembler les 
capacites de prestations des ressources et/ou services a partir des applications 
prestataires de ressources et/ou de services, on utilise une structure d'information 
dynanuque representative des offres de qualite de service a Fattention des utiHsateurs, 

S comprenant un en-tete de contexte de foumisseur de service, un bloc d'information 
representatif des specifications de qualite de service ofFertes par chaque service 
disponible, et un un bloc d'information representatif des specifications de qualite de 
service pour chaque service parmi une plurality de services. 

6, Procede selon Tune quelconque des revendications precedentes, 

10 caracterise en ce que pour traiter les informations regies et decider des operations de 
gestion a effectuer, on elabore des taches de gestion abstraites a Taide d'agents 
autonomes qui prennent en compte les besoins de qualite de servie QdS des utilisateurs, 
et les of&es de service dans renvironnement du reseau. 

7. Procede selon la revendication 6, caracterise en ce que lesctits agents 
15 sont des agents inteltigents, comportant : 

- une couche avertie pemnettant d'acqu6rir les besoins des utilisateurs du 
reseau et les offies de services; 

- une couche deliberative chargee de creer des tSches de gestion; 

- une couche operationndle executant les taches de gestion crees par la 
20 couche deliberative. 

8. Procede selon Tune quelconque des revendications precedentes, caraaerise 
en ce que la s<dsie des besoins des utilisateurs se fait par rintermediaire d'une interface 
homme-madiine comprenant un moyen d'entree d'information et un moyen d'afiBdiage. 
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